Really Simple Syndication (RSS) is a family of Extensible Markup Language (XML) file formats for web syndication, that is, provision of a channel of information by representing multiple resources in a single document. Web syndication is used for example by news websites and weblogs. Acronym RSS is also used to refer to Rich Site Summary and RDF Site Summary, however, meaning always the same RSS.
The RSS formats provide web content or summaries of web content together with links to the full versions of the content, and other meta-data. This information is delivered as an XML file called RSS feed, webfeed, RSS stream, or RSS channel.
RSS technology allows internet users to subscribe to websites that provide RSS feeds. Typically the content of these websites change regularly. Users are required to download a news aggregator that collects syndicated content, such as RSS and other XML feeds from the internet. The aggregator subscribes to RSS feed, and if new or updated content is available, retrieves the content. The aggregator can poll feed's Uniform Resource Locator (URL) at predetermined intervals and thereby retrieve updated content automatically. For a user, to obtain the feed items as quickly as possible, the user has to poll the URL in short enough intervals. For example, if the user wants to have the newly-arrived item available within ten minutes of its appearance, it must poll the source in an interval of less than ten minutes.
‘Atom’ is an XML-based document format for the syndication of web content such as weblogs and news headlines. Atom defines a feed format for representing and a protocol for editing Web resources such as weblogs, online journals and similar content. Atom framework is currently under standardization in Internet Engineering Task Force (IETF) Atom Publishing Format and Protocol (atompub) working group. The goal for the working group is to produce a single feed format and a single editing protocol.
Neither RSS nor Atom specifies a transport protocol for feeds, although hypertext transfer protocol (HTTP) is regularly used.
SIP is an application-layer control protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, for example, Internet multimedia conferences, Internet telephone calls, and multimedia distribution. SIP-specific Event Notification framework has been defined in Request for Comments (RFC) 3265 specification by Internet Engineering Task Force (IETF). SIP event framework is a SIP extension to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. The general concept is that entities in the network who are interested in the state information of other entities can subscribe to that information, and the other entities (or entities acting on their behalf) can send notifications when those states change.
Subscribers typically generate SUBSCRIBE requests and send them to notifiers to create subscriptions. Subscription is sent for a particular event and is associated with a SIP dialog. The “Event” header field of the SIP SUBSCRIBE request defines the type of state information which the subscriber is interested. Event packages define a set of state information to be reported by a notifier to a subscriber in NOTIFY requests. After receiving a new subscription, the notifier first acknowledges the subscription and then reports the current state information in a notification. If the subscription is not a ‘one-shot’ subscription, further notifications may be sent, for example, when the state information is changed. A subscriber acknowledges all received notifications.
Using Session Initiation Protocol (SIP) event framework for delivering RSS and Atom feeds has been described in U.S. utility application Ser. No. 11,121,539 of the same applicant filed on May 4, 2005. According to the prior patent application, polling RSS feeds very often for updates is not an optimal solution for mobile devices that have limited bandwidth and battery capacity.
Sometimes a user or application needs to perform a similar transaction with a number of remote users. For example, an instant messaging application that needs to send a particular message to many receivers needs to send the same message separately to each receiver. If a transaction to be repeated consists of a large request, or the number of recipients is high, or both, the access network of the sending party needs to carry a considerable amount of traffic. Completing all the transactions on a low-bandwidth access would require a long time.
This situation was improved by introducing Uniform Resource Identifier (URI)-List services in the network. URI-list is a list comprising one or more URIs, e.g., SIP URIs. The task of a SIP URI-list service is to receive a request that contains or references a URI-list and send a number of similar requests to the destinations, i.e., URIs, in this list. Thereby the request in transmitted only once over the low-bandwidth access interface and separate requests for each destination is created in the core network where the capacity is usually not a problem. Once the requests have been sent to the destinations, the URI-list service typically informs the sending party about their status. A URI-list service can take as an input a URI-list contained in the received SIP request itself or an external URI-list, e.g., the Request-URI is a SIP URI which is associated with a URI-list at the server. External URI-lists are typically created and managed using out-of-band mechanisms, such as XML Configuration Access Protocol (XCAP). Created URI lists may be stored in external servers, for example, in an XML Document Management Server (XDMS). Various servers, such as Instant Messaging (IM) and conference servers, can access and retrieve URI lists from the servers storing URI lists.